home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / virus / invrc501.zip / WHITEPA.PER < prev   
Text File  |  1993-06-11  |  40KB  |  977 lines

  1.                                                                   
  2.            Adaptive Expert System Anti-Virus Technology
  3.                                  
  4.                                  
  5.                                  
  6.                                  
  7.                                  
  8.                                  
  9.                                  
  10.                                  
  11.                                  
  12.                                  
  13.                                  
  14.                                  
  15.                                  
  16.              A White Paper prepared by Troy C. Klein,
  17.                 Product Manager for InVircible(r)
  18.                                  
  19.                                  
  20.                            June 11, 1993
  21.                                  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41. Copyright (c)  1992,1993      NetZ Computing, Ltd.,
  42.                               S.C.C., and Tayzen Corporation.
  43.  
  44.  
  45.                           - 1 -
  46.                                                                   
  47. Adaptive Expert System Anti-Virus Technology
  48.  
  49.  
  50.  
  51. The purpose of this paper is to introduce to the
  52. reader the Adaptive Expert System (AES) anti-virus
  53. concept.  The AES concept incorporates the ability
  54. to detect, locate, and remove unknown viruses.
  55. This is an alternative to the ubiquitous Virus
  56. Scanner and TSR technology (VS-TSR) which is
  57. limited to processing virus signatures known at
  58. the time of a product's release.  The AES
  59. technology is more efficient, is extremely
  60. difficult to compromise, is non-intrusive, and is
  61. actually user friendly.  As a bonus, you avoid the
  62. requirement of VS-TSR products that the user
  63. perpetually pay for updates that are ineffective.
  64. AES technology is much more sophisticated than VS-TSR 
  65. technology because AES technology emphasizes
  66. protection against viruses without altering memory
  67. usage, disk files, or customary usage patterns of
  68. a computer.  AES technology is able to accurately
  69. and completely restore 99.99+% of all virus-infected 
  70. executables that AES is protecting, and detect most 
  71. of the rest!
  72.  
  73.  
  74. Historical Background
  75. ---------------------
  76.  
  77. The introduction of AES by NetZ Computing Ltd. of
  78. Israel (NetZ) in September 1990 introduced
  79. heuristic capabilities to anti-virus technology.
  80. The product that NetZ released in 1990 with
  81. introductions in Israel and France was V-Care(tm),
  82. featuring the VGUARD AES.  The XSCAN AES enhanced
  83. V-Care in December 1990.  The introduction of V-Care 
  84. in the U.S.A. occurred in November 1991.
  85. VGUARD(tm) is unsurpassed in the detection and
  86. disinfection of virus attacks in the three known
  87. virus classes:  Boot Sector, FAT/Directory, and
  88. Executables.   XSCAN is unique in being able to
  89. locate the primary infection executables, even if
  90. one or more of the virus-introducing files are on
  91. a remote network drive and even if the viruses
  92. have never before been identified.  The V-Care
  93. product was renamed InVircible(r) in late 1992
  94. for worldwide marketing and distribution purposes.
  95.  
  96. NetZ 's pioneering contribution to the anti-virus
  97. effort was to transcend the VS-TSR technology that
  98. relied on CRCs or checksums.  The superior AES
  99. technology instead uses header-based validation
  100. signatures and sophisticated analyses of evidence
  101. of virus activity. Header-based signatures are a
  102. very reliable and effective technique for the
  103. detection of viruses, and provide an efficient
  104. mechanism for the complete restoration of infected
  105. executable files with no need to identify the
  106. specific infecting virus.  NetZ's header-based
  107. signatures file recovery methodology was presented
  108. to the NCSA/AVPD conference held in Washington,
  109. D.C., in November 1991.
  110.  
  111. After NetZ's introduction of AES technology in
  112. September 1990, other anti-virus packages have
  113. been unsuccessful in attempting to emulate various
  114. aspects of NetZ's AES technology.  NetZ still has
  115. the only anti-virus core technology that continues
  116. to be completely effective since its introduction.
  117. Users who obtained V-Care in September 1990 are
  118. still fully protected against the three known
  119. virus classes 32 months later, a track record of
  120. effectiveness no other distributed product is able
  121. to match.  The continued effectiveness of the
  122. September 1990 V-Care covers virus categories not
  123. yet identified when V-Care was introduced.  These
  124. categories include the polymorphic, mutating, and
  125. encrypting viruses.  Like the Energizer(tm) bunny,
  126. NetZ's AES technology keeps working and working.
  127.  
  128. By the end of 1991, NetZ enhanced the techniques
  129. that handle stealthy viruses to simplify recovery
  130. from the 1963 and the DIR-2 viruses.  The enhanced
  131. technique known as Inverse-Piggybacking is
  132. incorporated into the VGUARD AES.  The Hyper-Correlator 
  133. enhanced technique for locating primary
  134. infection executables is incorporated into the
  135. XSCAN AES.  Inverse-Piggybacking is described
  136. later on in this paper.
  137.  
  138.  
  139.                           - 2 -
  140.  
  141. To understand the practical benefits of the AES
  142. anti-virus paradigm, we will first review the
  143. characteristics of the earlier VS-TSR technology.
  144. This review includes coverage of the innate risks
  145. in continuing to use VS-TSR technology.
  146.  
  147.  
  148. Evaluating and Comparing the Performance of Anti-Virus Software
  149. ---------------------------------------------------------------
  150.  
  151. Evaluating anti-virus products is not a simple
  152. exercise.  Software packages may usually be
  153. examined by providing appropriate inputs and
  154. determining whether the resulting activities,
  155. results, and outputs are produced accurately and
  156. efficiently.  Evaluating anti-virus software is
  157. somewhat problematic, since testing with an
  158. inadequate product may let loose a virus with less
  159. than benign intent.  An inadequate product may not
  160. only give false positives, but will give false
  161. negatives if it is unable to detect all viruses.
  162. False positives are possibly more troublesome than
  163. false negatives, because mis-identification may
  164. cause the anti-virus product to undertake
  165. inappropriate remedial actions.  For users without
  166. a controlled environment for testing anti-virus
  167. products, what criteria are the best for making a
  168. decision on which anti-virus software to obtain?
  169. Are all anti-virus products based on the same
  170. technology?  Does the "number" of viruses known to
  171. an anti-virus product really matter?  This paper
  172. addresses these questions by comparing the AES
  173. technology of InVircible and the VS-TSR technology
  174. of other anti-virus packages.
  175.  
  176. There are two basic approaches to anti-virus
  177. technology.  The first approach is based on the
  178. assumption that viruses may be identified by an
  179. invariant sequence of bytes, or signature, before
  180. transfer to a computer's memory, diskettes, or
  181. hard disk (VS-TSR technology).  VS-TSR is based on
  182. the premise that viruses may be prevented from
  183. transferring into a computer's memory by pre-identification.  
  184. The VS-TSR approach also presumes
  185. that identification of viruses facilitates
  186. surgical removal once a virus is known.  The
  187. second approach of AES technology is based on 
  188. the premise that virus activity, not identification,
  189. is the mechanism by which any virus' presence may
  190. be detected and removed.  AES analyzes viruses by
  191. class (Boot Sector, DIR/FAT, or Executable) with
  192. the classification based on the characteristics of
  193. the virus in the user's computer.
  194.  
  195. VS-TSR technology assumes that you may prevent an
  196. infection by preventing entry of a virus.  This
  197. assumption is idealistic, because unknown viruses
  198. may enter a computer by many avenues, specifically
  199. any hardware with memory with which the computer
  200. is built or exposed to.  Viruses may have infected
  201. executables on hard drives, floppy drives, tape
  202. backups, and so on.  Purchasers of software are
  203. also never assured of virus-free diskettes, even
  204. from recognized brand name software manufacturers.
  205. With luck, a simple virus may be absolutely and
  206. positively identified if the virus is known due to
  207. its affecting someone else's computer first.
  208.  
  209. AES technology on the other hand acknowledges that
  210. pre-identification of viruses will never be 100%,
  211. meaning that 100% effective prevention of virus
  212. infection is also unattainable!  AES is structured
  213. to accurately do a complete restoration of virus
  214. infected systems and to locate the executables
  215. harboring the original infection without ever
  216. needing to know the identity of the virus.  VS-TSR
  217. systems may be able to detect many secondary
  218. infected executables and some primary infected
  219. executables.  However, the VS-TSR systems are
  220. unable to locate all infected executables with
  221. secondary infections unless the primary infected
  222. executables harbor only known viruses.
  223.  
  224.  
  225.                           - 3 -
  226.  
  227. The VS-TSR products face the daunting prospects
  228. of:
  229.  
  230.   >  identifying the increasing number of variants
  231.      (in both data and logic) of existing viruses,
  232.   >  the appearance of stealthy viruses that falsify
  233.      information reported by DOS,
  234.   >  the appearance of viruses that piggy-back on
  235.      programs that open and close many files (such as
  236.      anti-virus scanners),
  237.   >  the appearance of viruses the mutate themselves
  238.      or create mutations in their progeny,
  239.   >  the appearance of polymorphic viruses that are
  240.      able to select different scenarios that trigger
  241.      malevolent behavior and reproduction,
  242.   >  the appearance of viruses able to encrypt their
  243.      infections,
  244.   >  the appearance of viruses able to hijack TSRs,
  245.   >  the appearance of viruses able to build actual
  246.      virus instructions using innocuous code
  247.      sequences, and
  248.   >  the appearance of virus-writing software engines
  249.      (some with elaborate  "user-friendly" GUI interfaces).
  250.  
  251. Accordingly, the VS-TSR approach of relying on
  252. preemptive identification is increasingly
  253. ineffective and even dangerous if removal is
  254. attempted after mis-identification for a known
  255. virus.  Catastrophic damage is very likely to
  256. occur if removal of any virus is based on a
  257. removal technique for another virus.
  258.  
  259. How does AES technology rate in comparison with VS-TSR 
  260. technology?  What are valid criteria for
  261. evaluating the effectiveness of anti-virus
  262. technology?  Many rating schemes for VS-TSR
  263. products are based solely on the ability to detect
  264. the limited number of known viruses available to
  265. the rating organization.  The VS-TSR motivated
  266. rating schemes are insufficient to validly measure
  267. the power of AES technology that is not limited
  268. simply to the detection of known viruses.  To take
  269. the measure of AES technology, a more
  270. comprehensive and rigorous rating scheme is
  271. essential.  A tougher standard that AES technology
  272. meets is the scientific principal that it is
  273. better science to assume an assertion is invalid
  274. if any exception exists.
  275.  
  276. Using that tougher scientific standard, the
  277. assertion that AES technology is completely
  278. effective measures up.  Whether AES and VS-TSR
  279. technology are compared on the basis of detection
  280. of known viruses, on technical design, or on an
  281. ability to handle unknown viruses -- the technical
  282. superiority of AES technology remains evident.
  283. While looking at the following examination of AES
  284. and VS-TSR technology, note that the InVircible
  285. implementation of AES technology has an empty list
  286. of viruses that have been undetected, i.e.,
  287. InVircible has yet to meet a virus it couldn't
  288. handle.  VS-TSR technology on the other hand has
  289. focused on the easier task of increasing the
  290. number of detectable and known viruses.
  291.  
  292. A brief study of VS-TSR versus AES technology was
  293. undertaken in November 1992.  A representative 
  294. VS-TSR product with considerable marketing exposure
  295. was used for tests to validate concerns about 
  296. VS-TSR products.  This product's accompanying
  297. literature revealed that only about 10%  of the
  298. viruses it claims to identify are removable.
  299. Since actual tests are more illustrative than any
  300. claims, the representative VS-TSR product and
  301. InVircible (as the representative of AES
  302. technology) were tested for accuracy of virus
  303. identification and virus removal.
  304.  
  305.  
  306.                           - 4 -
  307.  
  308. Four viruses were used in the comparison of VS-TSR
  309. and AES:  Timor, Net Crasher, DIR-2, and MTE.
  310. Timor, a variant of the classic Jerusalem
  311. parasitic resident generic file infector virus,
  312. was captured at a site in Portugal.  Net Crasher,
  313. a virus derived from the Vienna parasitic 
  314. non-resident ".COM" infector virus, was captured 
  315. days before the comparison tests at the 
  316. American-Israeli Paper Mills in November 1992.  
  317. DIR-2 is a common resident directory infector virus.  
  318. MTE is a parasitic non-resident ".COM" infector virus
  319. with an embedded polymorphic encryption engine in
  320. the virus.
  321.  
  322. The representative VS-TSR scanner first 
  323. mis-identified Timor as Jerusalem or virus 1241 (it
  324. could not decide).  If this scanner had attempted
  325. to disinfect based on the assumption of Jerusalem
  326. or 1241, the "restored" files would not have been
  327. correctly restored.  The VS-TSR scanner was then
  328. shown Net Crasher, which it incorrectly identified
  329. as Parasite.  On the basis of the identification
  330. of Parasite, the scanner asked for and received
  331. permission to take the dramatic step of
  332. overwriting and then erasing the infected
  333. executables.  Not only were the identifications of
  334. Timor and Net Crasher incorrect, no restoration
  335. was available.  In comparison, the AES InVircible
  336. detected that the executables were infected by
  337. Timor and Net Crasher, and then received
  338. permission to restore completely and accurately
  339. the executables.  InVircible even detected that
  340. the executables recovered from Net Crasher have
  341. three bytes of the file overwritten at random!
  342.  
  343. For the DIR-2  tests, the DIR-2 virus was
  344. permitted to damage the directories of a DOS 5.0
  345. formatted hard disk.  Since DIR-2 "locks up" a PC,
  346. rebooting was done from a floppy drive using a DOS
  347. 3.3x bootable diskette.  After DIR-2 executions
  348. under DOS 5.0 and DOS 3.3x, every executable file
  349. in every directory on the hard disk was cross-linked 
  350. into a common cluster.  The root directory
  351. files became cross-linked as well.  The VS-TSR
  352. scanner incorrectly identified that every file was
  353. infected with Tequila instead of DIR-2.  The VS-TSR 
  354. scanner's attempt to remove Tequila instead of
  355. DIR-2 caused such extensive damage to low-level
  356. formatting that the hard disk had to be
  357. reformatted with low-level formatting tools
  358. typically available only to disk manufacturers.
  359. The hard disk was low-level formatted and then
  360. returned to the DIR-2 damaged state from which it
  361. was then quickly restored and disinfected by the
  362. InVircible Inverse-Piggybacking technique.  The
  363. restoration was exact and complete; no symptoms
  364. then remained to indicate that a DIR-2 infection
  365. had ever been present.
  366.  
  367. The fourth test was the MTE virus.  This
  368. polymorphic virus was mis-identified by the VS-TSR
  369. scanner as Pogue or at other times identified as
  370. Dame (an alias for MTE)  depending on which
  371. iteration of the MTE virus it was looking at.  The
  372. scanner's suggestion was to delete the files with
  373. the infection, having no removal algorithm.
  374. InVircible, when presented with the infected
  375. files, quickly and accurately restored the
  376. executables infected with MTE.
  377.  
  378.  
  379.                           - 5 -
  380.  
  381. Experiences with other VS-TSR products are
  382. similar.  VS-TSR products are unable to identify
  383. all known viruses accurately, they do not have
  384. disinfection capabilities for all viruses that
  385. they can identify, they often confuse distant
  386. variants with the original virus, and they do not
  387. have the ability to remove the infections that
  388. they are willing to attempt with precision and
  389. completeness.  The numbers of viruses have
  390. increased to a large enough population so that the
  391. number of signatures is now a problem for VS-TSRs.
  392. Users prefer not to give up more of the limited
  393. 640Kb of memory address space that DOS to
  394. accommodate a bigger online virus signature
  395. library.  So, VS-TSRs are beginning to choose
  396. between completeness, memory requirements, and
  397. speed.  This is resulting in the intentional
  398. omission of some known virus signatures from 
  399. VS-TSR signature libraries.  Some of the same
  400. products that are now deliberately not including
  401. virus signatures previously implied comprehensive
  402. coverage via virus signature counts.
  403.  
  404. Previous attempts at comprehensive coverage of
  405. virus signatures are being replaced by subjective
  406. inclusion rules.  This may not be reassuring to
  407. someone attacked by a virus that is no longer in
  408. the repertory of the VS-TSR product.  In contrast,
  409. InVircible's AES technology is uninvolved with
  410. virus signature libraries.  InVircible has a built-in 
  411. feature that enables it to capture the entire
  412. virus (logic and data) as a by-product of doing
  413. the normal 100% AES restoration of a virus
  414. infected executable.  This facility captures many
  415. previously unidentified virus candidates for
  416. inclusion in the VS-TSR signature libraries -- if
  417. there is room for them in the online VS-TSR
  418. signature libraries.
  419.  
  420. Using our self-imposed very tough scientific
  421. standard for effectiveness, there has not been one
  422. report that any virus has escaped detection by the
  423. InVircible AES technology.  In comparison, there
  424. are many circumstances where VS-TSR technology has
  425. proved to be inherently unreliable for the
  426. detection of viruses.  The correct restoration of
  427. any infected executable is outside of VS-TSR
  428. technological capabilities.
  429.  
  430.  
  431. What are AES Anti-Virus Techniques?
  432. -----------------------------------
  433.  
  434. The most fundamental characteristic of a
  435. successful computer virus is its ability to
  436. replicate and propagate into other programs or
  437. computers.  In many cases this is the only thing a
  438. virus does.  The replication and propagation
  439. characteristics of viruses form the basis for
  440. detection and analysis of virus activity by AES
  441. technology.  There are no other computer programs
  442. that behave this way and any logic module
  443. exhibiting this behavior is a priori a virus.
  444.  
  445. The dictionary defines "generic" as,
  446. "characteristic of a genus or class, applied to a
  447. large group or class, not specific".  "Heuristic"
  448. is dictionary defined as, "a method of education
  449. or computer programming in which the pupil or
  450. machine proceeds along empirical lines, using
  451. rules of thumb, to find solutions or answers."
  452. AES technology is both generic and heuristic.
  453.  
  454. Non-specific generic techniques have been applied
  455. for many years in an area where getting it right
  456. is of deadly crucial importance.  These techniques
  457. have been applied for more than 30 years in
  458. electronic warfare where waiting for precise
  459. identification of an opposing submarine or
  460. aircraft can have unfortunate consequences.  The
  461. effectiveness of the ECM (Electronic Counter
  462. Measures) techniques in the real world of military
  463. confrontation lead to their inclusion in 1989 by
  464. NetZ into the AES InVircible predecessor V-Care.
  465.  
  466.  
  467.                           - 6 -
  468.  
  469. The incorporation of heuristic techniques by NetZ
  470. advances the effectiveness of AES technology.
  471. Heuristic techniques look at combinations of
  472. expert rules, with the exact combinations used
  473. determined by the environment that AES operates
  474. in.   It is unreliable to presume that any subset
  475. of independently applied rules is sufficient to
  476. decide whether an executable is virus-infected or
  477. virus-free.  AES looks beyond the obvious 
  478. one-dimensional indicators of virus infection and
  479. activity with multi-dimensional analyses that
  480. identify secondary, tertiary, and so on
  481. indicators.  A distinct handicap of VS-TSR for the
  482. PC user is that the fixed analysis strategy of
  483. VS-TSR products is predictable and may be
  484. circumvented.  AES technology is unlikely to ever
  485. be circumvented (it is inappropriate to say never
  486. circumvented).  The generic and heuristic 
  487. anti-virus techniques of AES are based on the 
  488. innate properties of viruses themselves and take
  489. advantage of these properties for the detection
  490. and removal of viruses.
  491.  
  492.  
  493. Virus Detection Strategies -- Active and Passive Sensing of Virus Behavior
  494. --------------------------------------------------------------------------
  495.  
  496. AES technology uses both active and passive
  497. techniques to detect viruses with generic and
  498. heuristic methods.  Active detection is done by
  499. sensing viral behavior using detectable behaviors
  500. and side-effects of the virus itself.  Passive
  501. detection is based primarily on differential
  502. detection which is also known as integrity monitoring.
  503.  
  504. Active detection is based on the premise that
  505. certain phenomena are attributable only to
  506. viruses.  InVircible AES technology uses three
  507. primary phenomena that indicate the presence of a
  508. virus: memory stealing, the change in size of an
  509. executable file, and the occurrence of
  510. piggybacking.  Alterations to an executable file
  511. are not sufficient to indicate the presence of a
  512. virus, because a benign process may plausibly
  513. alter executable files.  For example, while having
  514. an executable do self-modification is not an ideal
  515. programming practice, self-modification is still
  516. often used by software developers instead of using
  517. a separate information (".INI") file.   Each of
  518. the three mentioned primary phenomenon is a
  519. reliable indicator of potential non-benign
  520. activity in the system.  Many viruses disclose
  521. their presence by exhibiting more than one of the
  522. mentioned phenomena.
  523.  
  524. Boot or partition infectors often avoid being
  525. overwritten in memory by an application by
  526. subverting DOS memory reporting functions -- which
  527. is called "memory stealing".  Other classes of
  528. virus infectors do the same, for example, the
  529. Maltese Amoeba whose activities are detected by
  530. inferring memory stealing activity.
  531.  
  532. An elementary anti-virus technique for detecting
  533. file-infecting viruses is to create ".COM" or
  534. ".EXE" files that are designed to entice the 
  535. file-infecting virus to attack, thus changing the size
  536. of the infected executable.  Non-stealth viruses
  537. may be revealed by this technique.  Stealthy
  538. viruses are able to conceal their attack on
  539. fabricated executables and go undetected from the
  540. "bait" executable strategy.   Stealthy viruses
  541. escape detection by subverting DOS's reporting
  542. functions that indicate the size of executables,
  543. and so on.  InVircible makes use of the Stealthy
  544. virus subversion of DOS reporting functions in a
  545. technique developed by NetZ called Inverse-Piggybacking.  
  546. Inverse-Piggybacking forces the
  547. virus to play the "Pied Piper" to InVircible,
  548. showing InVircible which executables are infected.
  549.  
  550.  
  551.                           - 7 -
  552.  
  553. Piggybacking viruses are some of the most
  554. problematic of viruses for VS-TSRs.  Many of the
  555. more common and successful viruses are
  556. piggybackers.  Some of the more well known
  557. piggyback viruses are Dark-Avenger (an alias is
  558. Eddie), 4096, Irish, Haifa and 1963.  New
  559. piggybackers enjoy many months of freedom from VS-TSRs, 
  560. because they have an unknown virus signature
  561. and they are spread by VS-TSRs as the VS-TSR
  562. conveniently scans through all of a PC's files.  A
  563. new piggybacker virus enjoys several months of
  564. anonymity after it emerges, allowing the
  565. piggybacker virus to go undetected by VS-TSRs and
  566. propagate extremely quickly, sometimes with
  567. assistance from VS-TSRs.  For example, the
  568. worldwide distribution of 4096 was facilitated by
  569. a VS-TSR.
  570.  
  571. There are two characteristics of scanners that
  572. promote them as major target vehicles for
  573. piggybacking viruses.  First, virus scanners are
  574. the quintessential programs that access every
  575. single executable file on a disk.  This paves the
  576. way for smart viruses to infect every file using
  577. the scanner as a convenient file opener and
  578. closer.  Historically, VS-TSRs have not been
  579. piggyback-resistant to unknown piggybacking
  580. viruses.  AES techniques are able to detect and
  581. remove piggybacking viruses because these viruses
  582. fall into one of the three known classes of
  583. viruses.  Piggybacking resistance was proposed at
  584. the November 1991 NCSA/AVPD conference as a
  585. recommended safety requirement for AV scanning
  586. products.  Effective implementation of this
  587. recommendation by VS-TSRs under all possible
  588. conditions has proved elusive.
  589.  
  590.  
  591. Header-Based Signatures for Integrity Monitoring and Recovery
  592. -------------------------------------------------------------
  593.  
  594. By definition, files that are infected by viruses
  595. are modified.  By monitoring the integrity of
  596. executable files, infections by unknown viruses
  597. are detectable.  Several approaches that are used
  598. by some anti-virus products include two file
  599. modification detectors:  checksums and CRCs.
  600. Neither of these two techniques is guaranteed to
  601. be effective in detecting virus modifications.
  602. Files are often modified by both benign procedures
  603. and by viruses, so checksums (with a CRC defined
  604. as a more complicated checksum) are unreliable as
  605. a method of detecting malicious changes to a file
  606. without numerous false alarms.  The number of
  607. benign exceptions is so large that checksum
  608. integrity validation is not a reliable anti-virus
  609. technique.  As a benign example, any alteration of
  610. the version table of the DOS 5.0 SETVER program
  611. will change the SETVER.EXE file's checksum.
  612. Similar examples of self-modifying executables are
  613. provided by many word processors or compilers.
  614.  
  615. No combination of exotic and complex calculations
  616. improves the effectiveness of checksums for 
  617. anti-virus usage.  Checksum strategies yield too many
  618. false-positives and they are easily compromised by
  619. a virus writer who replicates the checksum
  620. algorithm.  Checksums at best may be of use to
  621. assure that the file is not a replacement of an
  622. older file bearing the same name, or that a malicious 
  623. virus has not overwritten part of the file.
  624.  
  625.  
  626.                           - 8 -
  627.  
  628. Other anti-virus programs have used another 
  629. less-than-desirable technique of incorporating data
  630. into the executable as an "immunizing shell".  The
  631. "jacket immunization" process involves the
  632. addition (a virus-like activity!) of 700 to 1500
  633. bytes to each executable file as a protective
  634. shell.  When a jacket immunized and infected file
  635. is executed, the protective shell ideally discards
  636. the implanted virus code and restores the file.
  637. Jacket immunization has three major drawbacks:
  638. >  it is ineffective against stealthy viruses,
  639. >  there are programs that do not tolerate an
  640.    immunizing shell, with the DOS 5.0 SETVER.EXE
  641.    program especially disrupted, and
  642. >  last and least desirable, the requirement that
  643.    the infected file must be executed in order to
  644.    drop the virus.
  645.  
  646. There is a much faster, simpler, and more reliable
  647. way to indicate that a file has been modified by a
  648. virus using header-based integrity monitoring
  649. signatures.  The header of an executable file is
  650. found in the first few bytes of an ".EXE" file or
  651. ".COM" file.  All file infector viruses modify
  652. this portion of the executable file, with the
  653. exception of the Emmie virus.  The header and a
  654. few other parameters provide sufficient
  655. information for AES technology to detect a virus
  656. infection and then completely and accurately
  657. restore infected executable files (with the
  658. identity of the virus involved effectively irrelevant).
  659.  
  660. In contrast, the algorithmic removal of a virus
  661. from a file by a scanner fundamentally depends on
  662. the exact identification of the virus, the
  663. extraction of the original header from the virus
  664. code, the reconstruction of the header, and
  665. finally the eradication or truncation of the virus
  666. code from the file.  In brief, it is the
  667. application of a matched inverse algorithm to the
  668. executable file.  Each particular virus requires a
  669. unique algorithm for the eradication of the virus.
  670. The development of these unique eradication
  671. algorithms is becoming increasingly impossible to
  672. do in a timely manner.  In contrast, AES
  673. technology uses multiple techniques to assure that
  674. strategic parts of an executable file are
  675. unchanged rather than to have faith in customized
  676. virus removal algorithms.  The increasing number
  677. of closely related viruses and the appearance of
  678. polymorphic viruses makes assured recovery by
  679. scanner an unlikely event.
  680.  
  681. Header-based restoration of executable files skips
  682. the virus identification of VS-TSRs.  Restoration
  683. using header-based signatures is a superior
  684. alternative to the  jacket immunization technique
  685. used in some AV products.  Restoring an infected
  686. file via a protective shell provides a convenient
  687. platform for a virus to infect other files.  With
  688. the VS-TSR drawbacks and the availability of a
  689. very robust and successful alternative with AES
  690. technology, why use immunization?  Of all the
  691. products that practiced immunization in the past,
  692. only one continues to use it.
  693.  
  694.  
  695. Piggybacking and Inverse-Piggybacking
  696. -------------------------------------
  697.  
  698. Full Stealth viruses were introduced with the
  699. appearance of Frodo.  Frodo (an alias for 4096) is
  700. the first known virus that exhibited what is
  701. called full stealth virus behavior that is
  702. different from semi-stealth virus behavior.  A
  703. common property of full stealth viruses is that
  704. when a full stealth virus infected file is copied
  705. to another file with a non executable extension
  706. name, the copy is clean of the full stealth virus.
  707.  
  708.  
  709.                           - 9 -
  710.  
  711. Frodo instigated the development of the Inverse-
  712. Piggybacking AES technique.   Inverse-Piggybacking
  713. does not copy the processed file to another
  714. filename but rather swaps roles between the
  715. application and the virus.  The virus is in effect
  716. piggybacked by the AES anti-virus program and it
  717. is in fact the virus itself that guides the
  718. disinfection of all files previously infected by
  719. that same virus!  Inverse-Piggybacking turns out
  720. to be efficient against all known fully stealthy
  721. file infectors such as Whale, 1963, DIR-2 and
  722. others.  Inverse-Piggybacking provides a quick,
  723. efficient, and comprehensive method for dealing
  724. with the otherwise problematic DIR-2 virus.
  725.  
  726. Inverse-Piggybacking is extremely effective and
  727. efficient and is the only way to restore 
  728. virus-infected hard disks that would otherwise be
  729. recoverable only by low-level reformatting due to
  730. scrambling of the partition FAT table and likely
  731. corruption of the bad-sector table.  
  732. Inverse-Piggybacking is also much safer than passive
  733. removal of some viruses, 1963 for example.
  734.  
  735. A special and interesting case is the DIR-2 virus
  736. mentioned earlier in this paper. In many cases,
  737. passive virus scanners will not show a DIR-2
  738. infection, but the DOS CHKDSK command will
  739. indicate the appearance of cross-linking.  CHKDSK
  740. only indicates a problem; the user is left to
  741. wonder what actually happened to the hard disk.
  742. Damage caused by a specific full-stealthy virus
  743. will usually be recovered fully by Inverse
  744. Piggybacking when the same virus that caused the
  745. damage is resident in the computer memory.
  746.  
  747.  
  748. Restoration of computers that are already infected prior to 
  749.    installation of an AES product like InVircible
  750. -----------------------------------------------------------
  751.  
  752. First, InVircible does have an excellent virus
  753. scanner that knows all of the most common and
  754. widespread viruses that may be safely removed
  755. without knowing the status of an executable before
  756. an infection.  The AES scanner does not need to be
  757. updated frequently since it is a secondary tool,
  758. and the number of common viruses is far fewer than
  759. 1700 or so known viruses.
  760.  
  761. Second, the InVircible virus code hyper-correlator
  762. AES program XSCAN may be used to track down
  763. infected files, even those infected by encrypted
  764. viruses.  The hyper-correlator is able to list and
  765. remove all files infected by an unidentified virus.
  766.  
  767.  
  768. AES Generic Heuristic versus VS-TSR Technology -- A Summary
  769. -----------------------------------------------------------
  770.  
  771. Two factors are important in the comparison of AES technology
  772. versus VS-TSR technology.   First, viruses will
  773. continue to be written in larger numbers, although
  774. probably not at the apocalyptic rates predicted by
  775. some prognosticators.  Yet, this proliferation
  776. increases the likelihood that computers will be
  777. infected by viruses not previously identified by
  778. some other unfortunate user.  Preparing for the
  779. virus problem requires that the tools used are
  780. capable of dealing with unknown viruses that may
  781. not even exist today.
  782.  
  783.  
  784.                           - 10 -
  785.  
  786. Second, the most widespread and common viruses are
  787. initially non-destructive since they need the
  788. opportunity to spread.  The fact that a virus 
  789. (or its progeny) has become widespread indicates that
  790. it has not destroyed itself in the reproduction
  791. process, and that it has not been caught and
  792. removed.  A destructive virus inherently betrays
  793. its own presence and will lose its chances to
  794. propagate.   This rule -- The Survival Of The
  795. Fittest of computer viruses -- has been repeatedly
  796. proven with all common and widespread viruses
  797. known today and is fundamental to understanding
  798. the persistence of the computer virus problem.
  799. Viruses can be dealt with in a safe and effective
  800. manner even after a computer is infected.
  801.  
  802. Consider the rationale of the VS-TSR.  The primary
  803. role of the VS-TSR is to prevent the entrance of
  804. viruses.  Only known viruses may readily and
  805. effectively excluded from a computer by a VS-TSR.
  806. A virus known to a VS-TSR may sometimes be removed
  807. by the cleaning option of the VS-TSR.  Unknown
  808. viruses are ignored or mis-identified as a known
  809. virus.  There is another major pitfall of VS-TSRs:
  810. they may themselves be hijacked as a vehicle to
  811. attack a PC's executables.   The question is:  Why
  812. suffer the penalties of the VS-TSR, including loss
  813. of memory space, frequent false alarms, a conduit
  814. for viruses, and degraded computer performance,
  815. when the same result is obtainable by other means?
  816.  
  817. The AES approach suggests that once in the
  818. computer, any virus must one way or the other
  819. become active and reveal the virus' presence even
  820. if the virus is dormant for some period of time.
  821. AES technology that is used regularly (at each
  822. booting for example), allows complete removal of
  823. viruses from AES protected executables.   Since
  824. viruses must be non-destructive for a while in
  825. order to propagate, there is no reason to be
  826. alarmed by the fact that the computer's defenses
  827. have been "penetrated".  There is no 100%
  828. effective software technique that prevents the
  829. introduction of a computer virus.  On the other
  830. hand, if the virus is destructive (which is highly
  831. unlikely if the virus made all the way to your
  832. computer!), then most probably it can not be
  833. stopped by a TSR or any other software-based method.
  834.  
  835. PC users using initially low-cost VS-TSRs are
  836. reluctant to switch to a more cost effective AES
  837. implementation until they understand the perpetual
  838. maintenance cost of VS-TSR "updates".  For
  839. nostalgic reasons, many PC users are especially
  840. attached to their favorite, and usually out-of-date 
  841. virus scanner.  This "Maginot Line" defense
  842. philosophy is unfortunately applied to computer
  843. viruses.  VS-TSR users often state a variation of,
  844. "It must be OK, because it (the anti-virus scanner
  845. product) has not indicated any problems," so far!
  846.  
  847. AES virus removal is facilitated principally by
  848. header-based restoration based on information
  849. extracted from the executable.  The AES method is
  850. non-intrusive (it does not alter programs as
  851. jacket immunization does) and is extremely
  852. efficient and safe.  AES technology will
  853. increasingly show its advantages as the expanding
  854. numbers of mutating, polymorphic, and encrypting
  855. viruses develops.  Even though the AES
  856. technological approach is a better defense against
  857. viruses; acceptance will preferably happen by
  858. users before the potential economic costs of the
  859. VS-TSR approach are unfortunately realized.
  860. InVircible is the only commercially available
  861. implementation of AES technology.
  862.  
  863.  
  864.                           - 11 -
  865.  
  866. As a final note, anti-virus software will never be
  867. a substitute for other defensive computing
  868. practices.  This involves keeping a complete set
  869. of backups, providing electrical and communication
  870. line protections, and becoming very aware of what
  871. is normal for a specific computer.  An AES product
  872. such as InVircible will assist a well-prepared PC
  873. user minimize resources needed by the user to keep
  874. his PC from becoming fatally affected by virus infections.
  875.  
  876.  
  877. About the InVircible Author
  878. ---------------------------
  879.  
  880. Zvi Netiv is an Electronics Engineer, who headed
  881. R&D projects in the Israel Defense Forces and in
  882. the Israel Aircraft Industries for 27 years.  In
  883. 1989 Zvi started doing applied research in
  884. computer virus techniques and accumulated several
  885. copyrighted works in this domain.  Zvi Netiv is a
  886. columnist and lecturer in the Israeli professional
  887. computer community and internationally.  In 1991
  888. he established his own company, NetZ Computing
  889. Ltd.  NetZ's products have been distributed
  890. worldwide under the names V-Care and V-Guard, with
  891. V-Care and V-Guard combined and renamed as
  892. InVircible(r) in 1992.
  893.  
  894.  
  895. About InVircible Availability
  896. -----------------------------
  897.  
  898. The North American and Pacific Rim distributor of
  899. InVircible(r) is S.C.C. is located at 18721 Mooney
  900. Drive in Gaithersburg, Maryland  20879, U.S.A.
  901. The telephone number is 1(301)590-0001.  The
  902. telefax number is 1(301)590-0003.  InVircible may
  903. be obtained in single unit or multiple unit
  904. quantities.  Agency or corporate site licenses are
  905. available.  InVircible is offered in the English,
  906. Hebrew, and French languages (manuals and user
  907. interfaces).  Operating systems supported are DOS
  908. 3.x through 6.x releases from Microsoft, IBM, and
  909. Digital Research; and OS/2 1.x, and OS/2 2.x.
  910. Availability for Windows NT and Novell's DOS 7.0 
  911. is pending.
  912.  
  913.  
  914.                           - 12 -
  915.  
  916. Glossary
  917. --------
  918.  
  919.   Boot Sector -- The disk sector of a bootable
  920.   hard disk partition that the hardware of a PC
  921.   locates and executes automatically upon power-up
  922.   or reboot.
  923.  
  924.   CRC -- Cyclical Redundancy Check.
  925.  
  926.   DOS -- Disk Operating System.
  927.  
  928.   GUI -- Graphical User Interface.  For example,
  929.      Microsoft's Windows 3.1.
  930.  
  931.   Maginot Line --  Built after World War I by
  932.      France along the French--German border as a
  933.      series of fortifications that no land army could
  934.      go through (but could go around and over).
  935.  
  936.   PC -- Personal Computer.  For this paper, the
  937.      IBM AT architecture is implied.
  938.  
  939.   R&D -- Research and Development.
  940.  
  941.   TSR -- Terminate-and-Stay-Resident.  A DOS
  942.      capability allowing a logic module to hook into
  943.      the operating system's interrupt table.  After
  944.      the module is hooked into the interrupt table
  945.      and returns control to DOS, DOS may resume
  946.      execution of another program such as an 
  947.      anti-virus program.
  948.  
  949.  
  950. Trademarks
  951. ----------
  952.  
  953. (R)IBM and OS/2 are registered trademarks of
  954.    International Business Machines Corporation.
  955.  
  956. (TM) AT is a trademark of International Business
  957.      Machines Corporation.
  958.  
  959. (R)Microsoft  and Windows NT are registered
  960.    trademarks of Microsoft Corporation.
  961.  
  962. (TM)V-Guard and V-Care are trademarks of NetZ
  963.     Computing, Ltd. and Sela Computer Consultants.
  964.  
  965. (R)InVircible is a registered trademark of NetZ
  966.    Computing, Ltd. and Sela Computer Consultants.
  967.  
  968.  
  969. Copyright Notice
  970. ----------------
  971.  
  972. This paper is copyrighted (c) 1992,1993 by the Author
  973.   for Tayzen Corporation, and by NetZ Computing,
  974.   Ltd., and by Sela Consultants Corporation
  975.   (S.C.C.).  All Rights Reserved.  Printed in the
  976.   United States of America, June 11, 1993.
  977.